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1  Introduction 

specialization  is  a  growing  area  of  interest  in  the  operating  systems  community.  OS  components 
specialized  to  some  particular  circumstance  can  offer  enhanced  performance,  functionality,  or  both. 
Complimentary  partial  evaluation  techniques  for  automatically  specializing  programs  are  also  reach¬ 
ing  maturity.  However,  the  problem  of  managing  specialization  remains:  how  to  specify  a  special¬ 
ization,  when  to  apply  it,  and  when  to  remove  it.  This  problem  is  particularly  important  for  long- 
running  programs  such  as  operating  systems,  where  specializations  are  likely  to  be  temporary. 

This  paper  presents  an  object-oriented  framework  for  specifying  specializations  in  long-running 
programs  such  as  operating  systems.  This  model  is  based  on  the  following  concepts: 

•  Inheritance  allows  replacement  implementations  of  of  member  functions.  We  thus  use  a  graph 
of  sub-classes  to  specify  a  set  of  potential  specializations  of  a  given  facility  by  replacing 
generic  implementations  with  specialized  implementations. 

•  Specializations  in  long-running  programs  are  temporary,  because  the  particular  circumstances 
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that  permit  the  use  of  a  specialized  implementation  are  likely  to  change  eventually.  We  thus 
support  temporary  and  even  optimistic  specializations  [16]. 

•  Ensuring  that  it  is  valid  to  use  a  specialized  implementation  can  be  more  difficult  than  cre¬ 
ating  the  specialized  implementation  [16].  We  thus  use  a  formal  method  to  specify  when  a 
specialization  is  valid.  This  lets  us  automatically  detect  when  specialization  circumstances 
have  changed  [8],  and  also  automatically  generate  specialized  implementations  using  partial 
evaluation  [6,  5]. 

Section  2  describes  our  specialization  model,  which  is  applicable  both  in  00  operating  systems 
and  in  legacy  kernels.  Section  3  describes  compilation  techniques  for  this  model.  Section  4  briefly 
describes  some  closely  related  work,  and  Section  5  concludes  this  position  paper. 

2  Specialization  Classes 

We  first  describe  our  model  using  an  example,  and  then  explain  some  details.  Figure  1  illustrates 
specialization  of  a  file  system:  the  open  file  object  FS,  which  understands  the  operations  read  ( ) 
and  write  ( ) ,  is  said  to  be  the  target  of  the  specialization. 

Following  modern  usage  [1,  14],  we  use  the  term  type  to  refer  to  the  interface  exposed  by  an 
object  and  the  term  class  to  refer  to  the  method  code  and  the  instance  variables  that  implement  that 
interface.  Hence,  the  type  of  the  file  describes  the  fact  that  it  can  be  read  and  written;  in  an  00 
system  the  type  is  merely  the  type  of  the  FS  object,  and  in  a  legacy  OS  coded  in  a  non-00  language 
it  is  the  type  signature  of  the  set  of  procedures  that  provides  the  file  system  functionality. 

The  specialization  plan  is  a  definition  of  all  the  ways  in  which  the  file  system  can  be  special¬ 
ized.  In  each  specialization,  some  of  the  methods  of  the  target  are  replaced  by  various  specialized 
implementations.  The  methods  specialized  by  the  specialization  plan  are  the  set  of  specializable 
functions  that  are  replaced  by  various  specialized  implementations.  Thus  the  specialization  plan 
encapsulates  the  specializations  to  be  applied  to  the  system,  independent  of  the  degree  of  encapsu¬ 
lation  provided  by  the  system’s  source  language. 

The  various  specialization  options  within  a  plan  are  organized  into  a  partial  order  of  specializa¬ 
tion  classes  according  to  the  relation  “more  specialized  than.”  Each  specialization  class  adds  some 
degree  of  specialization  to  the  classes  it  inherits  from,  e.g.  NFS  is  a  specialization  of  generic,  and 
NFS/exclusive  is  a  specialization  of  both  NFS  and  exclusive.  Each  specialization  class  describes  a 
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Figure  1 :  Example:  Specialization  of  a  File  Object 

specialization  state  that  the  specialized  facility  can  achieve.  The  “generic”  -specialized  state  is  the 
unique  top  of  the  partial  order  of  specialization  classes. 

Each  specialization  class  specifies  the  conditions  that  make  the  specialization  applicable,  and 
a  subset  of  the  members  in  the  specialization  plan  to  be  replaced  with  specialized  methods.  The 
conditions  of  a  specialization  class  imply  the  conditions  of  each  of  its  parents.  The  truth  of  the 
conditions  can  change  over  time,  and  thus  must  be  monitored  as  described  in  Section  2. 1 . 

Specialization  plans  are  compiled  into  specialized  object  generators,  which  when  new’d  create 
specialized  objects  as  shown  in  Figure  1 .  A  specialized  object  is  a  wrapper  around  the  object  being 
specialized.  The  specialized  object  represents  the  state  of  an  instance  of  a  specialization  plan,  i.e., 
bindings  from  the  values  in  the  conditions  to  data  in  the  target,  and  bindings  from  the  specializable 
functions  to  the  specialized  methods.  We  view  the  type  of  the  target  object  as  being  unchanged  by 
the  specialization;  from  the  point  of  view  of  the  client,  the  same  set  of  messages  is  understood,  and 
they  have  the  same  effects.  Thus,  the  type  of  the  specialization  object  is  statically  determined  by 
the  type  of  the  target. 

In  contrast,  the  class  of  the  object  changes  dynamically  according  to  the  truth  of  the  conditions, 
and  causes  changes  in  the  method  code  bound  to  the  specializable  functions.  Looking  a  little  more 
closely,  it  may  in  fact  the  the  case  that  the  type  changes:  for  example,  if  the  conditions  indicate 
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that  a  certain  message  will  never  be  sent,  we  might  create  a  specialized  object  that  eliminates  that 
method  altogether!  However,  our  methodology  guarantees  that  any  such  changes  in  type  will  be 
invisible  to  the  client. 

2.1  Conditions:  Quasi-Invariants 

Conditions  specify  invariants.  A  true  invariant  is  a  classical  invariant:  a  property  of  the  system 
that  is  guaranteed  to  be  true  at  all  times,  stated  as  an  expression  using  system  variables  that  must 
evaluate  to  “true.”  A  quasi-invariant  is  a  property  that  is  likely  to  remain  true,  but  may  become 
false  at  some  future  time.  Specifying  conditions  using  invariants  allows  the  following  key  steps  in 
the  specialization  process  to  be  automated. 

Invariants  can  be  used  by  partial  evaluators  to  automatically  prepare  a  specialized  implemen¬ 
tation  that  has  been  optimized  using  the  invariants.  Our  use  of  invariants  for  specialization  was 
originally  inspired  by  the  invariant  input  specification  for  Tempo  [6,  5],  a  powerful  partial  evalu¬ 
ator  for  C.  Partial  evaluation  to  exploit  specialization  gives  us  a  formal  relationship  between  the 
conditions  and  the  optimized  implementation. 

Partial  evaluation  is  independent  of  whether  a  condition  is  an  invariant  or  a  quasi-invariant. 
However,  specializations  that  depend  on  quasi-invariants  are  not  always  valid,  but  instead  depend 
on  some  temporary  circumstance  that  begins  when  the  quasi-invariants  become  true,  and  ends  when 
the  quasi-invariants  become  false.  For  instance,  file  system  access  can  be  optimized  using  a  quasi¬ 
invariant  that  the  file  is  not  shared  [16],  but  this  condition  can  change  unexpectedly  if  a  separate 
process  opens  the  file. 

Our  hand-specialization  experiments  showed  that  locating  all  components  of  the  kernel  that  af¬ 
fect  the  state  of  quasi-invariants  can  be  more  difficult  than  the  task  of  crafting  specialized  implemen¬ 
tations.  We  have  thus  developed  tools  for  locating  kernel  components  that  can  potentially  invalidate 
quasi-invariants,  described  in  the  following  section. 

2.2  Guarding  for  Changes  in  Quasi-Invariants 

We  have  developed  two  ways  to  locate  kernel  components  that  can  potentially  alter  quasi-invariant 
state.  One  is  based  on  type-checking  the  kernel  source  code,  and  the  other  is  based  on  fine-grained 
virtual  memory  protection.  These  techniques  are  discussed  at  length  in  [8],  but  what  they  produce 
is  a  list  of  kernel  source  code  statements  that  may  violate  quasi-invariant  state.  These  writes  to 
quasi-invariant  state  must  be  guarded. 
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However,  frequently  such  statements  are  accessing  heap-allocated  data  structures,  and  only 
a  few  of  many  of  these  structures  actually  control  a  specialization,  e.g.  the  quasi-invariant 
inode .  ref  count  ==  1  may  be  true  of  some  particular  inode,  but  there  are  thousands  of  in¬ 
stances  of  the  inode  struct  in  the  running  kernel.  The  guards  placed  around  writes  decide  whether 
the  write  is  to  an  actual  quasi-invariant,  or  only  a  write  to  a  value  of  the  same  type  as  a  quasi¬ 
invariant. 

We  distinguish  among  structs  of  the  same  type  between  those  that  contain  quasi-invariant  terms 
and  those  that  do  not  by  inserting  a  Specialization  IDentifier  field  (SID).  In  the  case  that  the  inode 
struct  is  the  instance  referred  to  in  the  quasi-invariant  expression,  the  SID  field  points  to  the  special¬ 
ized  object  that  depends  on  that  quasi-invariant.^  The  specialized  object  then  performs  the  guarded 
write.  For  example,  consider  this  update  to  inode .  ref  count; 

inode . ref count  =  some_value; 

A  guarded  update  of  the  inode .  ref  count  would  be  written  as: 

inode_set_ref count (some_value,  SID)  ; 

The  inode_set_ref  count  function  writes  the  inode .  ref  count  field  in  any  case,  but  also 
atomically  adjusts  any  specialized  components  that  depend  on  quasi-invariant  expressions  that  de¬ 
pend  on  this  inode .  ref  count  value. 

2.3  Responding  to  Quasi-Invariant  Changes:  Replugging 

When  a  quasi-invariant  is  violated,  the  specialized  object  must  adapt  its  specialized  implementation 
of  the  facility  to  the  new  circumstance  without  relying  on  the  quasi-invariant.  One  very  common 
action  to  be  taken  by  the  specialized  object  is  to  replace  the  dependent  specialized  components  with 
other,  differently  specialized  components,  or  with  generic  components.  This  replacement  is  called 
replugging,  and  requires  fast,  safe,  concurrent  dynamic  linking.  The  problem  is  to  facilitate  very 
low  latency  execution  of  a  function  via  an  indirect  function  pointer,  while  concurrently  allowing 
the  pointer  to  be  changed.  Locks  could  be  used,  but  locks  may  also  substantially  degrade  perfor¬ 
mance.  In  [7],  we  describe  a  portable  algorithm  that  supports  low-latency  invocation  of  replaceable 
functions  while  allowing  concurrent  update  of  pointers  to  those  functions. 

lA  more  complex  scheme  is  used  when  struct  instances  are  shared  among  multiple  specializations,  which  we 
omit  for  simplicity. 
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3  Translation  and  Specialization 


Our  previous  efforts  have  manually  applied  our  various  specialization  tools  [7,  8,  16,  17].  Auto¬ 
matic  translation  of  specialization  plans  should  convert  the  high  level  specification  of  how  to  spe¬ 
cialize  the  system  into  running  code  that  integrates  the  various  components. 

3.1  Specialization  Plans 

The  specialization  plan  describes  all  possible  ways  in  which  the  facility  can  be  specialized.  Given  a 
list  of  quasi-invariants,  there  is  an  exponential  number  of  combinations  of  such  invariants,  resulting 
in  an  exponential  number  of  specialized  functions.  Specialization  classes  allow  the  programmer  to 
specify  which  combinations  are  important,  and  thus  should  be  exploited. 

The  specialization  plan  is  translated  into  a  code  template  for  a  specialized  object,  and  two  lists. 
The  code  manages  the  data  structures  described  in  Figure  1 .  The  lists  describe  each  specialization 
class,  and  are  fed  to  other  specialization  tools  as  follows: 

specializable  functions  The  list  of  specializable  functions  is  taken  from  the  specializa¬ 
tion  plan  and  built  into  the  specialized  object,  and  is  fed  to  the 
Tempo  partial  evaluator  (see  Section  3.2). 

quasi-invariants  The  list  of  quasi-invariants  is  fed  to  the  guarding  tools,  and  to 

Tempo. 

3.2  Partial  Evaluation 

A  specialization  class  declares  an  opportunity  for  specialization,  and  is  described  by  a  list  of 
(quasi-)invariants.  If  all  the  predicate  conditions  are  of  the  form  variable  =  const-value 
or  struct .  field-name  =  const-value,  the  specialized  implementations  can  be  automat¬ 
ically  derived  by  a  partial  evaluator.  Notice  that  such  an  automatic  tool  could  be  extended  to  deal 
with  other  classes  of  predicate  conditions,  e.g.  of  the  form  variable  <  const-value.  If  the 
complexity  of  the  predicates  is  beyond  the  current  capabilities  of  the  partial  evaluator,  the  program¬ 
mer  can  still  provide  a  hand- written  implementation. 

We  are  using  Tempo,  a  partial  evaluator  for  C  programs  developed  at  IRIS  A,  [5,  6,  4].  Given 
a  program  and  part  of  its  inputs,  it  generates  a  specialized  version  of  the  program  in  which  all  the 
computations  depending  on  the  known  inputs  are  performed.  Tempo  processes  a  program  in  two 
phases. 
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First,  an  analysis  is  performed,  to  decide  which  parts  of  the  program  are  to  be  reduced  (elimi¬ 
nated),  and  which  other  are  to  be  left  in  the  specialized  program.  Note  that  the  analysis  phase  doesn’t 
need  the  concrete  values,  it  just  propagates  the  known/unknown  information.  The  interface  to  this 
first  phase  is  the  analysis  context,  which  contains: 

•  a  list  of  the  known  inputs,  which  can  be  either  variables  or  struct  field  names 

•  a  list  of  the  functions  to  be  specialized 

In  a  second  phase,  the  program  is  specialized,  based  on  the  annotations  produced  by  the  first 
phase  and  some  concrete  values  for  each  known  input  previously  declared.  The  interface  to  this 
second  phase  is  the  specialization  context,  binding  an  actual  value  to  each  invariant  variable. 

4  Related  Work 

Object-oriented  OS  research  has  advanced  the  state  of  the  art  in  the  interface  provided  to  applica¬ 
tions,  and  advanced  the  ability  of  operating  systems  to  be  dynamically  configured.  In  particular, 
Choices  [2,  11],  AL-l/D  [15],  and  Apertos  [18]  have  investigated  ways  in  which  object-orientation 
can  be  used  for  OS  re-configuration.  Kiczales  has  been  exploring  the  general  question  of  how  ob¬ 
jects  can  be  used  as  a  meta-interface  [13]. 

OS  customization  has  also  been  studied  outside  the  00  community.  The  SPIN  project  allows 
replacement  OS  components  to  be  loaded  into  the  kernel.  SPIN  uses  a  combination  of  static  type 
checking  and  run-time  checks  to  bound  the  damage  potential  of  replacement  components,  but  leaves 
the  correctness  of  applying  a  specialization  up  to  the  application.  The  Aegis  project  provides  more 
customizability  by  placing  most  OS  functionality  in  a  user-level  library  attached  to  user  applica¬ 
tions  [10].  We  discuss  some  of  these  approaches  in  [9], 

At  the  language  level,  specialization  classes  are  similar  to  Chambers’  predicate  classes  [3], 
which  allow,  for  example,  the  class  of  a  buffer  object  to  depend  on  whether  the  buffer  is  full, 
partially-full,  or  empty.  Specialization  classes  can  be  thought  of  as  an  implementation  of  predicate 
classes  in  which  guarding  is  used  to  change  the  class  of  an  object  in  response  to  independent,  con¬ 
current  events;  this  idea  is  hinted  at  in  reference  [3],  but  was  not  fully  worked  out  or  implemented. 
Specialization  classes  can  also  be  applied  to  systems  written  in  a  language  such  as  C,  in  which  the 
objects  are  more  conceptual  than  real. 
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Specialization  plans  are  similar  to  the  Aster  distributed  application  configuration  language  [12]. 
Aster  operates  at  a  higher  level,  using  predicates  that  cannot  be  checked  mechanically,  but  can  be 
reasoned  about  mechanically. 

5  Conclusions  and  Future  Research 

We  have  proposed  an  object-oriented,  mostly  declarative  model  for  specifying  specializations  in 
long-running  programs  such  as  operating  systems.  In  the  near  term,  we  expect  to  demonstrate  the 
utility  of  this  programming  model  for  enhancing  flexibility  and  performance  in  operating  systems 
through  specialization.  Subsequently,  we  hope  that  this  model  will  prove  itself  to  be  a  valuable 
addition  to  the  family  of  modularity  techniques. 
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